Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000025_owner-urn-ietf _Tue Aug 20 17:44:47 1996.msg

Internet Message Format | 1997-02-19 | 11KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA01443 for urn-ietf-out; Tue, 20 Aug 1996 17:44:47 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA01438 for <[e-mail]>; Tue, 20 Aug 1996 17:44:35 -0400
Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA19209  (mail destined for [e-mail]); Tue, 20 Aug 96 17:44:22 -0400
Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id OAA12400; Tue, 20 Aug 1996 14:44:15 -0700
Message-Id: <[e-mail]>
From: Terry Allen <[e-mail]>
Date: Tue, 20 Aug 1996 14:44:14 PDT
In-Reply-To: "Ronald E. Daniel" <[e-mail]>
       "[URN] revision 1 of the NAPTR draft" (Aug 16,  1:49pm)
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: "Ronald E. Daniel" <[e-mail]>, [e-mail]
Subject: Re: [URN] revision 1 of the NAPTR draft
Sender: [e-mail]
Precedence: bulk
Reply-To: Terry Allen <[e-mail]>
Errors-To: [e-mail]

| From [e-mail] Tue Aug 20 14:27:44 1996
| Received: from ruby.ora.com (ruby.ora.com [198.112.208.25]) by rock.west.ora.com (8.6.13/8.6.11) with ESMTP id OAA11790 for <[e-mail]>; Tue, 20 Aug 1996 14:27:42 -0700
| Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by ruby.ora.com (8.6.13/8.6.11) with ESMTP id RAA04724 for <[e-mail]>; Tue, 20 Aug 1996 17:25:52 -0400
| Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA26186 for <[e-mail]>; Tue, 20 Aug 1996 15:27:33 -0600 (MDT)
| Message-Id: <[e-mail]>
| X-Sender: [e-mail]
| X-Mailer: Windows Eudora Pro Version 2.2 (32)
| Mime-Version: 1.0
| Content-Type: text/plain; charset="us-ascii"
| Date: Tue, 20 Aug 1996 15:32:57 -0600
| To: Terry Allen <[e-mail]>
| From: Ron Daniel <[e-mail]>
| Subject: Re: comments on draft
| Status: OS
|
| Here are you original comments - I've flagged the ones
| I have tried to address.
|
|
| At 12:34 PM 8/20/96 PDT, you wrote:
| >This is pretty clean and clear.  A few assorted comments:
| >
| >| "Must" or "Shall" - Software that does not behave in the mannar that this
| >|   namespace to another agency. Evaluating the NAPTR recors in the correct
| >
| >typos
|
| Got em.
|
| >
| >All quite clear to here,
| >
| >| * The replacement field is one of two fields used for the rewrite rules.
| >|   If the rewrite is a simple substitution of a domain name, that name is
| >|   given in the replacement field. The replacement field is a domain name
| >|   (subject to compression if a DNS sender knows that a given recipient is
| >|   able to decompress names in this RR type's RDATA field). If the rewrite
| >|   is more complex than a simple substitution of a domain name, the
| >|   replacement field should be set to . and the regexp field used.
| >
| >You might by way of emphasis say "simple substitution of a domain name
| >for the entire domain name submitted".  If that's what you mean.
|
| I've tried something a little different on that point.
| >
| >| * The regexp field is the other field that may be used for rewrite rules.
| >|   The regexp field is a String containing sed-style substitution expressions.
| >
| >Expressions in the plural suggests a script with multiple regexps.  Not that
| >I'd read this carefully when I wrote you earlier today.
|
| now is "a sed-style regular expression".
|
| >|   These are applied to the original URN and yield the next domain name
| >|   to be queried.
| >
| >So that the server could supply (as a terminal NAPTR?) regexps that extracted
| >info from the opaque part of the URN, if it knows they would work right
| with all
| >opaque parts of all its URNs.  But this is not what you want for
| size/performance
| >reasons.
| >
| >Now suppose I can redirect all NAPTR inquiries to my name space with a
| >script of 64 lines (64 regexps).  Will it actually be more efficient
| >to return 64 NAPTR records or one long one?  Or does it come to the
| >same thing?  (I dunno, just a thought; you guys are the architects.)
| >
| >| The first step in the resolution process is to find out about the DUNS
| >| namespace. The namespace identifier, duns, is extracted from the URN,
| >| prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might
| >
| >For us know-nothings, you might say where this first query goes.  As a child,
| >I thought that Station Identification was some central studio that individual
| >stations invoked from time to time.  But there isn't any place called urn.net,
| >right?  Where is duns.urn.net?
| >
|
| No action on any of the preceding points.
|
| >| Since our example RR specified the "s" flag, it was terminal. Our
| >| next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which
| >
| >You need to say "as we can't use dunslink, our next action ..." ?
|
| Got it.
|
| >
| >| conjunction with a long TTL for *.urn.net records, the average number
| >| of probes to DNS for resolving DUNS URNs would approach one.
| >
| >| ;;                  order pref flags service replacement       regexp
| >| cid.urn.net IN NAPTR 100  10   ""     ""       .        "/.+@([^@]+)/\1/i"
| >
| >I tried that regexp with sed:
| >
| >% sed 's/.+@([^@]+)/\1/i' < foo
| >sed: ``\digit'' out of range: s/.+@([^@]+)/\1/i
| >
| >but:
| >
| >% sed 's/.*@\([^@]*\)/\1/' < foo
| >mordred.gatech.edu
| >
| >where foo is urn:cid:[e-mail]
| >
| >My sed(1), under Sun OS 5.4 and 4.1 (where it's sed (1v))
| >doesn't have an /i anyway, useful though that would be.
|
| Added additional caveats about '(', '*', etc. But point about
| your sed not having /i is still valid. Please raise it and we
| can see if anyone on the list has the POSIX standard handy.
|
| >
| >| The flags field tells us that this is the last NAPTR patterns we
| >| should see, and after the rewrite (a simple replacement in this case) we
| >| should look up SRV records to get information on the hosts
| >| that can provide the necessary service.
| >
| >If that fails, what do I do, ask for NAPTR records from the same
| >places I asked for SRV records?
| >
|
| No action.
|
| >| Flags
| >|        A String giving flags to control aspects of the rewriting. Flags
| >|        are single characters from the alphabet [A-Z0-9]. The case of
| >
| >"are single alphanumeric characters"
| >
|
| You might suggest "from the set of characters [A-Z0-9]".
|
| >|        the alphabetic characters is not significant.
| >|
| >|        At this time only two flags, "S" and "A", are defined. "S" means
| >|        that the next lookup should be for SRV records instead of NAPTR
| >|        records. "A" means that the next lookup should be for A records.
| >|        The S and A flags are mutually exclusive, and resolution libraries
| >|        SHOULD signal and error so that bad NAPTRs can be quickly detected.
| >
| >"signal an error to the server"?  does the client care?
| >
| >| shells, there is a good chance that when you think you are saying "\\" you
| >| are actually saying "\".
| >
| >And you may need to say \\\ or \\\\ to get things through your shell.
|
| Here is where the additional caveats on '('et. al went.
| >
| >| The "a" flag allows the next lookup to be for A records rather than
| >| SRV records. Since there is no place for a port specification in the
| >| NAPTR record, when the "A" flag is used the specified protocol must
| >| be running on its default port.
| >
| >That seems suboptimal.  Why not make a place for it?  (Any good
| >reason will suffice.)
| >
| >|     Once a NAPTR has "matched" a URN, the client MUST NOT consider
| >|      any NAPTRs with a higer value of order than that of the matching NAPTR,
| >
| >typo.  And NAPTRs don't match URNs but rather domain names (right?).
|
| Got the typo.
|
| >|      (A match is defined as:
| >|       1) The NAPTR provides a replacement domain name
| >|       2) The regular expression matches the URN
| >|      )
| >
| >"The result of applying the regular expression matches the URN."
|
| Ugh. And I disagree with you on "match" as I said earlier. I still
| think I am right on this, but we can let the list judge.
|
| >
| >|   -  If a record at a particular order matches the URI, but the client
| >|      doesn't know the specified protocol and service, the client should
| >|      continue to examine records that have the same order. The client
| >|      MUST NOT consider records with a higher value of order. This is
| >|      necesary to make delegation of portions of the namespace work.
| >
| >typo.
|
| Got "necessary".
|
| >  And, this rationale could well be inserted above, at "Once a NAPTR".
| >Client writers will do what they want so long as
| >they don't feel the need to claim conformance, so supplying the
| >rationale is a good way to persuade them to do it right.  Hey,
| >it worked with Netscape, right?
|
| I added a bit to "Once a NAPTR...".
| >
| >|   -  When multiple RRs have the same "order", the client should use
| >|      the value of the preference field to select the next NAPTR to
| >|      consider. However, because of preferred protocols or services,
| >|      estimates of network distance and bandwidth, etc. clients
| >|      may use different criteria to sort the records.
| >
| >That's unclear.  What does "sort" mean here?  It's the first time
| >in the document that the word appears in text, rather than code.
|
| Changed "sort" to "select the next record to process".
|
| >|   -  If the lookup after a rewrite fails, clients are strongly encouraged
| >|      to report a failure, rather than backing up to pursue other rewrite
| >|      paths.
| >
| >Answer to my earlier question; might say this earlier.
|
| Not real clear on this comment.
|
| >
| >
| >Regards,
| >
| >--
| >       Terry Allen      O'Reilly & Associates, Inc.   [e-mail]
| > "In going on with these experiments, how many pretty systems do we build,
| >  which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
| >        A Davenport Group sponsor     http://www.ora.com/davenport/
| >
| >
| Ron Daniel Jr.                       email: [e-mail]
| Advanced Computing Lab               voice: [phone]
| MS B287                                fax: [phone]
| Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
| Los Alamos, NM, USA  87545       tautology:"Conformity is very popular"
|
|


Regards,

--
       Terry Allen      O'Reilly & Associates, Inc.   [e-mail]
 "In going on with these experiments, how many pretty systems do we build,
  which we soon find ourselves obliged to destroy?"  -  Benjamin Franklin
        A Davenport Group sponsor     http://www.ora.com/davenport/